When a fault occurs somewhere in a communication network, a Network Element (NE) will send a notification, an alarm, to the network management system. The alarm usually contains certain information that the NE knows about the origin, probable cause and severity of the alarm, e.g.:                Time—which gives the time the alarm was issued.        Object ID—which identifies the Managed Object in the NE sending the alarm.        Severity—which indicates the severity of the alarm, in a range lowest-highest.        Event Type—which gives some indication of what happened.        Probable Cause—which gives some indication of why it happened.        Specific Problems—which clarifies what happened.        Proposed Repair Actions—which gives some suggestion about what to do.        
The task for the service provider (potentially aided by some automatic algorithms) is to analyze all the received alarms in terms of network and service impact, and trigger appropriate actions to mitigate the faults.
A non-trivial task in this process is to identify, based on a potentially very large number of alarms from different network elements, the actual faults (root causes) which are causing the alarms. This is generally referred to as alarm correlation, and there exists several methods, such as neural network assisted, rule, cognitive or flow-based methods, for performing alarm correlation.
Another important task in this process is to prioritize the received alarms, in order to judge which alarms are most important and need to be resolved first. The Severity fields of the individual alarms can serve as one input to this prioritization. There are methods proposed that automatically assign alarm priority, based on neural networks that continuously learn from manually assigned priorities in trouble-tickets.
WO2005/032186 describes a method for Performance Management of Cellular Mobile Packet Data Networks which involves capturing raw traffic traces over standardized interfaces of an operational cellular mobile data network, and correlating the information to build a traffic and session database. This involves parsing through various signalling messages to construct the association between subscribers, sessions and transactions. As a result, a user session data base is created and maintained that contains traffic information for users and locating the session to certain cell locations and identities, among them IP addresses of certain nodes in the data path.
For a service provider it is important to be able to determine the severity of alarms in terms of user and service impact. Prioritization of alarms is today mostly performed manually by network administrators, based on their experience and support systems, which is a very time consuming task.
The alarm Severity field can help in a first rough prioritization of alarms, for example an alarm of Critical severity, indicating that a link between two NEs is broken is obviously more important to resolve than alarms of Minor severity. However, there is only a weak correlation between the alarm Severity field and the actual priority that is manually assigned to an alarm. Also when there are several NEs issuing alarms of the same severity at the same time the prioritization process becomes more complex, and the Severity field is of little help.
Two basic examples show the difficulty of user and service aware alarm prioritization:                A High Priority alarm from an NE that is currently not serving any users should receive lower priority than a Medium Priority alarm from an NE that is serving 1000 Gold subscription users.        An alarm from an NE that is currently delivering a high priority (e.g. high margin) end-user service should receive higher priority than an alarm from an NE that only delivers best effort traffic.        
One main problem with existing methods is that they do not take into account the current user activity and traffic situation. Therefore it is not possible to prioritize the alarms in terms of how they affect users and services in the network.